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Detailed Action 

This office action is in response to tlie correspondence received on April 3, 2008. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or deschbed as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the phor art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Farinacci etal (US Pat No: 5,519,704) in viewof Tseung (US Pat No: 5,036,518), 
hereafter referred to as Farinacci and Tseung, respectively. 

1 . As to Claims 1 , 4, and 7, Farinacci teaches through Tseung: Receiving, by a 
server computer, a request to perform a task for a plurality of computers over a 
network (column 5, lines 50-53, Farinacci), wherein the task comprises installing 
a software application or updating a software application (column 40, lines 51-66, 
Tseung); Performing said task using a multicast message communicated from 
said server computer over said network, wherein the performance of said task is 
triggered by an event occurring on said server computer or said network (column 
5, lines 55-57, Farinacci); Updating a task status table by said server, wherein 
said task status table indicates whether said task has been completed for each 
said plurality of computers; Receiving, by said server computer, a request to 
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complete said tasl< from a first computer (see column 5, lines 53-55, Farinacci); 
Prioritizing requests to complete said task; if more than one request is received 
by said server computer from each of a plurality of computers (see column 48, 
lines 41-54, Tseung); Determining whether said task was completed for said first 
computer using said task status table (see column 5, lines line 60-63, Farinacci); 
Performing said task using a unicast message communicated from said server 
computer over said network to said first computer in accordance with said 
determination (see column 5, lines 64-67, Farinacci) and said prioritization (see 
column 48, lines 41-54, Tseung); and Updating said task status table, indicating 
whether said task has been completed for said first computer 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the tasks 
software updates and installs and doesn't teach the status table and also does 
not teach the tasks being triggered by events. Farinacci is also silent regarding 
prioritizing requests. In the same field of endeavor, Tseung teaches a design 
allowing for software installs and updates through multicasts (column 33, lines 
60-62 and column 40, lines 51-66, Tseung). The disclosure also teaches how 
one-to-one (unicast) data transfers are allowed (column 1, lines 25-58 and 
column 40, lines 31-51, Tseung). In addition, means by which to maintain the 
status of tasks in a computing device that is handling tasks is obvious and well 
known in the art. Tseung teaches how the retransmission station maintains data 
structures (table) to keep track of the status of messages (tasks or program 
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transmissions) to different recipients (Figure 40 and column 18, lines 16-47, 
Tseung). For instance, it can record if there are crc errors. When no errors are 
left, it is known that the messages have been transmitted completely and 
correctly (column 36, line 21- column 37, line 15, Tseung). Plus, Tseung teaches 
how events trigger tasks as claimed (see column 1 8, lines 59-67; column 1 9, 
lines 21-56; column 22, lines 19-32; column 23, line 53 - column 24, line 19; and 
column 26, line 32 - column 27, line 5; Tseung) Finally, Tseung also teaches 
how when requests from more than one computer are received, the requests are 
serialized (equivalent to prioritizing requests); see column 48, lines 41-54, 
Tseung. The serializing of requests is a prioritizing of requests based on time. 
Therefore, it would have been obvious to one skilled in the art, during the time of 
the invention, to have combined the teachings of Farinacci with those of Tseung 
to allow software and/or updates to be sent using the guaranteed, reliable and 
secure one-to-many technique (column 40, lines 51-54, Tseung)). 

2. As to Claims 2, 5 and 13, Farinacci teaches through Tseung: Wherein said 
determining whether said task was completed for said first computer comprises: 
Receiving an identifier for said first computer; Searching a task status table using 
said identifier; Retrieving a status indicator associated with said identifier; and 
Determining whether said task was completed for said first computer using said 
status indicator (see column 2, lines 57-63, Farinacci). 
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(While Farinacci teaclies a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 
also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
obvious to one skilled in the art, during the time of the invention, to have 
combined the teachings of Farinacci with those of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 

3. As to Claims 3, 6, 8, and 1 1 , Farinacci teaches through Tseung: Wherein said 
receiving said request to complete said task from said first computer comprises: 
Determining whether said first computer is in communication with said network; 
and Sending said request to complete said task from said first computer (see 
column 53-55, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 



Application/Control Number: 09/892,296 Page 6 

Art Unit: 2145 

also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
obvious to one skilled in the art, during the time of the invention, to have 
combined the teachings of Farinacci with those of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 

4. As to Claim 9, Farinacci teaches through Tseung: A storage medium: Said 
storage medium including stored instructions that, when executed by a 
processor, result in receiving, by a server computer, a request to perform a task 
for a plurality of devices over a network (see column 5, lines 50-53, Farinacci), 
performing said task using a multicast message communicated from said server 
computer over said network, wherein the performance of said task is triggered by 
an event occurring on said server computer or said network (see column 5, lines 
55-57, Farinacci), receiving, by said server computer, a request to complete said 
task from at least one device (see column 5, lines 53-55, Farinacci), prioritizing 
requests to complete said task, if more than one request is received by said 
server computer from each of a plurality of devices (see column 48, lines 41 -54, 
Tseung), determining whether said task was completed for said at least one 
device, and performing said task using a unicast message communicated from 
said server computer over said network to said at least one device in accordance 
with said determination (see column 5, lines 60-67, Farinacci) and said 
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prioritization (see column 48, lines 41-54, Tseung), wherein the task comprises 
copying a file, installing a software application or updating a software application 
(column 40, lines 31-66, Tseung)). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the tasks 
of software updates and installs and doesn't teach the status table and also does 
not teach the tasks being triggered by events. Farinacci is also silent regarding 
prioritizing requests. In the same field of endeavor, Tseung teaches a design 
allowing for software installs and updates through multicasts (column 33, lines 
60-62 and column 40, lines 51-66, Tseung). The disclosure also teaches how 
one-to-one (unicast) data transfers are allowed (column 1, lines 25-58 and 
column 40, lines 31-51, Tseung). In addition, means by which to maintain the 
status of tasks in a computing device that is handling tasks is obvious and well 
known in the art. Tseung teaches how the retransmission station maintains data 
structures (table) to keep track of the status of messages (tasks or program 
transmissions) to different recipients (Figure 40 and column 18, lines 16-47, 
Tseung). For instance, it can record if there are crc errors. When no errors are 
left, it is known that the messages have been transmitted completely and 
correctly (column 36, line 21- column 37, line 15, Tseung). Plus, Tseung teaches 
how events trigger tasks as claimed (see column 1 8, lines 59-67; column 1 9, 
lines 21-56; column 22, lines 19-32; column 23, line 53 - column 24, line 19; and 
column 26, line 32 - column 27, line 5; Tseung) Finally, Tseung also teaches 
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how when requests from more than one computer are received, the requests are 
serialized (equivalent to prioritizing requests); see column 48, lines 41-54, 
Tseung. The serializing of requests is a prioritizing of requests based on time. 
Therefore, it would have been obvious to one skilled in the art, during the time of 
the invention, to have combined the teachings of Farinacci with those of Tseung 
to allow software and/or updates to be sent using the guaranteed, reliable and 
secure one-to-many technique (column 40, lines 51-54, Tseung)). 

5. As to Claim 10, Farinacci teaches through Tseung: Wherein the stored 

instructions, when executed by a processor, further result in determining whether 
said task was completed for said at least one device by receiving an identifier for 
said at least one device, searching a task status table using said identifier, 
retrieving a status indicator associated with said identifier, and determining 
whether said task was completed for said at least one device using said status 
indicator (see column 2, lines 57-63, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 
also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
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obvious to one sl<illed in tlie art, during tlie time of tlie invention, to liave 
combined tlie teacliings of Farinacci witli tliose of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 

6. As to Claim 12, Farinacci teaches through Tseung: A storage medium; Said 
storage medium including stored instructions that, when executed by a 
processor, result in receiving, by a server computer, a request to send 
information to a plurality of devices (see column 5, lines 50-53, Farinacci), 
sending said information, from said server computer, to said plurality of devices 
using a broadcast message, wherein sending of said information is triggered by 
an event occurring on said server computer or said network (see column 5, lines 
55-57, Farinacci), receiving a request for said information from at least one 
device (see column 5, lines 53-55, Farinacci), prioritizing requests for said 
information, if more than one request is received by said server computer from 
each of a plurality of devices (see column 48, lines 41-54, Tseung), determining 
whether said at least one device received said information, and sending said 
information, from said server computer, to said at least one device using a 
unicast message in accordance with said determination, and updating said task 
status table, wherein said task status table comprises a status indicator indicating 
whether said information has been received by said at least one device (see 
column 5, lines 60-67, Farinacci). 
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(While Farinacci teaclies a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the tasks 
of software updates and installs and doesn't teach the status table and also does 
not teach the tasks being triggered by events. Farinacci is also silent regarding 
prioritizing requests. In the same field of endeavor, Tseung teaches a design 
allowing for software installs and updates through multicasts (column 33, lines 
60-62 and column 40, lines 51-66, Tseung). The disclosure also teaches how 
one-to-one (unicast) data transfers are allowed (column 1, lines 25-58 and 
column 40, lines 31-51, Tseung). In addition, means by which to maintain the 
status of tasks in a computing device that is handling tasks is obvious and well 
known in the art. Tseung teaches how the retransmission station maintains data 
structures (table) to keep track of the status of messages (tasks or program 
transmissions) to different recipients (Figure 40 and column 18, lines 16-47, 
Tseung). For instance, it can record if there are crc errors. When no errors are 
left, it is known that the messages have been transmitted completely and 
correctly (column 36, line 21- column 37, line 15, Tseung). Plus, Tseung teaches 
how events trigger tasks as claimed (see column 1 8, lines 59-67; column 1 9, 
lines 21-56; column 22, lines 19-32; column 23, line 53 - column 24, line 19; and 
column 26, line 32 - column 27, line 5; Tseung). Finally, Tseung also teaches 
how when requests from more than one computer are received, the requests are 
serialized (equivalent to prioritizing requests); see column 48, lines 41-54, 
Tseung. The serializing of requests is a prioritizing of requests based on time. 
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Therefore, it would liave been obvious to one sl<illed in tlie art, during tlie time of 
tlie invention, to liave combined the teachings of Farinacci with those of Tseung 
to allow software and/or updates to be sent using the guaranteed, reliable and 
secure one-to-many technique (column 40, lines 51-54, Tseung)). 

7. As to Claim 14, Farinacci teaches through Tseung: Wherein the stored 

instructions, when executed by a processor, further result in receiving a request 
for said information by connecting said at least one device to said network and 
sending said request for said information from said at least one device (see 
column 5, lines 60-67, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 
also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
obvious to one skilled in the art, during the time of the invention, to have 
combined the teachings of Farinacci with those of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 
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8. As to Claim 15, Farinacci teaclies tlirougli Tseung: A storage medium; said 
storage medium including stored instructions that, when executed by a 
processor, result in receiving, by a server computer, a request to perform a task 
for a plurality of devices over a network (see column 5, lines 50-53, Farinacci), 
performing said task using a multicast message communicated from said server 
computer over said network, wherein the performance of said task is triggered by 
an event occurring on said server computer or said network (see column 5, lines 
55-57, Farinacci), receiving, by said server computer, a request to complete said 
task from at least one device (see column 53-55, Farinacci), prioritizing requests 
to complete said task, if more than one request is received by said server 
computer from each of a plurality of devices (see column 48, lines 41-54, 
Tseung), searching a task status table using an identifier, retrieving a status 
indicator associated with said identifier, determining whether said task was 
completed for said at least one device using said status indicator (see column 2, 
lines 57-63, Farinacci), and performing said task using a unicast message 
communicated from said server computer over said network to said at least one 
device in accordance with said determination (see column 5, lines 60-67, 
Farinacci) and said prioritization (see column 48, lines 41-54, Tseung), wherein 
the task comprises installing a software application or updating a software 
application (column 40, lines 31-66, Tseung). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the tasks 
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of software updates and installs and doesn't teach the status table and also does 
not teach the tasks being triggered by events. Farinacci is also silent regarding 
prioritizing requests. In the same field of endeavor, Tseung teaches a design 
allowing for software installs and updates through multicasts (column 33, lines 
60-62 and column 40, lines 51-66, Tseung). The disclosure also teaches how 
one-to-one (unicast) data transfers are allowed (column 1, lines 25-58 and 
column 40, lines 31-51, Tseung). In addition, means by which to maintain the 
status of tasks in a computing device that is handling tasks is obvious and well 
known in the art. Tseung teaches how the retransmission station maintains data 
structures (table) to keep track of the status of messages (tasks or program 
transmissions) to different recipients (Figure 40 and column 18, lines 16-47, 
Tseung). For instance, it can record if there are crc errors. When no errors are 
left, it is known that the messages have been transmitted completely and 
correctly (column 36, line 21- column 37, line 15, Tseung). Plus, Tseung teaches 
how events trigger tasks as claimed (see column 1 8, lines 59-67; column 1 9, 
lines 21-56; column 22, lines 19-32; column 23, line 53 - column 24, line 19; and 
column 26, line 32 - column 27, line 5; Tseung) Finally, Tseung also teaches 
how when requests from more than one computer are received, the requests are 
serialized (equivalent to prioritizing requests); see column 48, lines 41-54, 
Tseung. The serializing of requests is a prioritizing of requests based on time. 
Therefore, it would have been obvious to one skilled in the art, during the time of 
the invention, to have combined the teachings of Farinacci with those of Tseung 
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to allow software and/or updates to be sent using the guaranteed, reliable and 
secure one-to-many technique (column 40, lines 51-54, Tseung)). 



9. As to Claim 16, Farinacci teaches through Tseung: Wherein the stored 
instructions, when executed by a processor, further result in receiving said 
request to complete said task from at least one device by connecting said at least 
one device to said network, and sending said request to complete said task from 
said at least one device (see column 5, lines 60-67, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 
also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
obvious to one skilled in the art, during the time of the invention, to have 
combined the teachings of Farinacci with those of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 



10. As to Claim 17, Farinacci teaches through Tseung: A server, said server having a 
task manager module to manage complete of a task for a plurality of target 
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devices using a multicast message communicated from said server, wlierein tlie 
tasl< comprises installing a software application or updating a software 
application and wherein performance of said task is triggered by an event 
occurring on said server (column 40, lines 51-66, Tseung); a plurality of target 
devices, said plurality of target devices each having a task finisher module to 
request completion of said task if uncompleted, wherein said requests to 
complete said task are prioritized by said task manager module (see column 48, 
lines 41-54, Tseung), and wherein the task finisher module is configured to install 
or update applications; and A network to communicate information between said 
server and said plurality of target devices to complete said task (see column 4, 
lines 40-47, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the tasks 
of software updates and installs and doesn't teach the status table and also does 
not teach the tasks being triggered by events. Farinacci is also silent regarding 
prioritizing requests. In the same field of endeavor, Tseung teaches a design 
allowing for software installs and updates through multicasts (column 33, lines 
60-62 and column 40, lines 51-66, Tseung). The disclosure also teaches how 
one-to-one (unicast) data transfers are allowed (column 1, lines 25-58 and 
column 40, lines 31-51, Tseung). In addition, means by which to maintain the 
status of tasks in a computing device that is handling tasks is obvious and well 
known in the art. Tseung teaches how the retransmission station maintains data 
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structures (table) to keep track of the status of messages (tasks or program 
transmissions) to different recipients (Figure 40 and column 18, lines 16-47, 
Tseung). For instance, it can record if there are crc errors. When no errors are 
left, it is known that the messages have been transmitted completely and 
correctly (column 36, line 21- column 37, line 15, Tseung). Plus, Tseung teaches 
how events trigger tasks as claimed (see column 1 8, lines 59-67; column 1 9, 
lines 21-56; column 22, lines 19-32; column 23, line 53 - column 24, line 19; and 
column 26, line 32 - column 27, line 5; Tseung). Finally, Tseung also teaches 
how when requests from more than one computer are received, the requests are 
serialized (equivalent to prioritizing requests); see column 48, lines 41-54, 
Tseung. The serializing of requests is a prioritizing of requests based on time. 
Therefore, it would have been obvious to one skilled in the art, during the time of 
the invention, to have combined the teachings of Farinacci with those of Tseung 
to allow software and/or updates to be sent using the guaranteed, reliable and 
secure one-to-many technique (column 40, lines 51-54, Tseung)). 

1 1 .As to Claim 18, Farinacci teaches through Tseung: Further comprising a task 
handler module for each of said plurality of target devices to complete said task 
for said plurality of target devices (see column 4, lines 40-47, Farinacci). 

(While Farinacci teaches a design allowing for tasks to be performed through 
the use of unicast and multicast messages, Farinacci does not disclose the task 
being software updates and installs. In the same field of endeavor, Tseung 
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teaches a design allowing for software installs and updates through multicasts 
(column 33, lines 60-62 and column 40, lines 51-66, Tseung). The disclosure 
also teaches how one-to-one (unicast) data transfers are allowed (column 1 , 
lines 25-58 and column 40, lines 31-51, Tseung). Therefore, it would have been 
obvious to one skilled in the art, during the time of the invention, to have 
combined the teachings of Farinacci with those of Tseung to allow software 
and/or updates to be sent using the guaranteed, reliable and secure one-to-many 
technique (column 40, lines 51-54, Tseung)). 

12. The obviousness motivation applied to claims 1 , 4, 7, 9, 12, 15 and 17 are 
applicable to their respective dependent claims. 

Response to Remarks 

The amendment received on April 3, 2008 has been carefully examined but is not 
deemed fully persuasive. In lieu of the claim amendments, the 1 12-type rejection has 
been overcome and hence that rejection is withdrawn. The 103-type rejection using the 
Farinacci and Tseung prior arts continue to stand though. The current amendment 
features independent claim amendments to add the feature of, "prioritizing requests to 
complete said task, if more than one request is received by said server computer from 
each of a plurality of computers." The applicant contends that neither prior art teach this 
claim limitation, the examiner disagrees. Tseung teaches how when requests from 
more than one computer are received, the requests are serialized (equivalent to 
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prioritizing requests); see column 48, lines 41-54, Tseung. The serializing of requests is 
a prioritizing of requests based on time. The claims themselves fail to specify the 
prioritizing is based on any factor other than time, hence the Tseung art's teachings of 
serialization are deemed equivalent to the claimed limitation of prioritization. 



Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to AZIZUL CHOUDHURY whose telephone number is 
(571)272-3909. The examiner can normally be reached on M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jason Cardone can be reached on (571) 272-3933. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding tlie status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/A. C./ 

Examiner, Art Unit 2145 



/Jason D Cardone/ 
Supervisory Patent Examiner, Art Unit 2145 



